home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 5 / Night Owl's Shareware NOPV 05 - Night Owl Publisher (PDSI_005) (7082) (1990).iso / 034a / mnp.txt < prev    next >
Text File  |  1991-08-04  |  50KB  |  835 lines
  1.  
  2.                                  High Speed Modems
  3.  
  4. We  have  received numerous  messages  asking  about high  speed  modems, their
  5. capabilities  and compatibility  between  modems from  different manufacturers.
  6. The following text  basically discusses the US Robotics HST 9600 bps modems and
  7. the Hayes V-Series 9600 bps modems.  It also covers the subject of v.32 modems.
  8. Such as the Prometheus ProModem. One of the more reliable modems released on
  9. the market some 2 1/2 yrs ago. This modem is 100% v.32 compatable. Which means
  10. it will connect (communicate) with "ANY v.32 modem." Well worth the $'s spent.
  11.  
  12. 1) The old USR HST  had a top transmission speed  of 9600 bps.  This  is before
  13.    taking into account any kind of  MNP compression.  Typical throughputs  with
  14.    the old  HST ranged  from 1150  cps  on a  compressed file  with the  modem-
  15.    compression-DISABLED  to  1900  cps  on  a  regular text  file  with  modem-
  16.    compression-ENABLED.
  17.  
  18.    The HST  will only transmit  at 9600 bps when  connected to another  HST but
  19.    will connect at 300/1200/2400 baud to other standard modems.
  20.  
  21. 2) The new  USR HST (termed  the 1440) is  able to  transmit data at  14400 bps
  22.    (again, this is  before taking into  account MNP compression, etc).  Typical
  23.    throughputs with  the  new HST  will range  from about  1500-1700  cps on  a
  24.    compressed file with modem-compression-DISABLED to about 2300-2400  cps on a
  25.    text  file with  modem-compression-ENABLED -- this  is assuming  that you've
  26.    opened your comm port at 38400 bps.
  27.    The HST will  only transmit at 9600  bps when connected  to another HST  but
  28.    will connect at 300/1200/2400 baud to other standard modems.
  29.  
  30. 3) The Hayes V-Series 9600  modems are similar to the old  USR HST described in
  31.    #1 above.   You will typically see throughputs  as high as 1900  cps on text
  32.    files but only about 960 cps on compressed files.
  33.  
  34.    The Hayes  V-Series 9600 will  only transmit at  9600 bps when  connected to
  35.    another V-Series 9600 modem but will  connect at 300/1200/2400 baud to other
  36.    standard modems.
  37.  
  38. 4) Hayes has recently begun shipping its V-Series modems with new ROM  chips in
  39.    them giving  them v.42  compatibility.   This means that  the V-Series  9600
  40.    modems can  now provide  an error-corrected  session when  connected to  any
  41.    regular MNP modems at 2400 bps.  This is because  v.42 implements MNP levels
  42.    1 through  4  (which excludes  MNP  compression).   You will  typically  see
  43.    throughputs of about 260-280  cps on a 2400 bps line  due to MNP's stripping
  44.    of the start and stop bits.
  45.  
  46. 5) The  v.32 modems (such  as those made  by US Robotics and  MultiTech) run at
  47.    9600 bps  and will  give you similar  throughputs to  those described  in #1
  48.    above (i.e.  v.32 will give you slower transmission speeds than will the new
  49.    HST's running at  14400 described in #2).   However, the simple advantages
  50.    are that it provides you  with better "interactive response times"  (such as
  51.    when typing) and that  because v.32 is a CCITT "standard"  they will connect
  52.    at 9600  bps to modems made by OTHER manufacturers.   By "other" I mean that
  53.    you can connect US Robotics v.32's to MultiTech v.32's to any  other v.32's.
  54.    The v.32 standard appears to be one that remain for some time to come ..  so
  55.    purchasing  a v.32  modem may be  a better  investment if you  are concerned
  56.    about  future  compatibility.   However,  v.32  still  costs  more than  the
  57.    proprietary standards such as the HST 9600 or the V-Series 9600.
  58.  
  59. 6) The USR  Dual Standard is BOTH a  v.32 and an HST modem.   When it is in the
  60.    "HST  mode" everything said in #2 above  (about the new 1440 HST's) is true.
  61.    When it is in "v.32 mode" then everything said in #5 (about v.32 modems)  is
  62.    true.  In other words in v.32 mode you will not get the full speed advantage
  63.    of the Dual Standard for file transfers.   However, one BIG advantage to the
  64.    Dual  Standard is that it is compatible not  only with the v.32 standard but
  65.    with  all of the existing  HST modems as  well.  This  may or may  not be an
  66.    advantage  for you  depending on  which modems  you frequently dial  into or
  67.    which modems dial into you.
  68.  
  69. 7) Hayes is  working on a  v.32 modem that  is similar to the  v.32 description
  70.    given in #5 above.   I cannot comment further  on this modem due to  lack of
  71.    details that have been given to me.
  72.  
  73.            What is v.32?  What's the difference between it and v.42?
  74.  
  75. The v.32 standard is a "modulation" standard.   I like to compare it to the  AM
  76. and FM standards used  in radio broadcasting.   Not only are they at  different
  77. frequencies but they use different modulation  techniques.  There are different
  78. modulation standards for 300,  1200 and 2400 baud.  The v.32 standard is a full
  79. duplex  (data going both  ways simultaneously at the  rated speed) standard for
  80. 4800 and 9600 bps connections.
  81.  
  82. The v.42  standard is an error  correction standard.   It is a method  by which
  83. data is packetized and sent between modems to ensure that the data that arrives
  84. at the receiving end is the same as what was transmitted.  It also includes the
  85. ability  to compress  data  on the  fly  to  enable higher  throughput  without
  86. requiring a different modem modulation scheme.
  87.  
  88. MNP is another error correction standard.   In fact, the v.42 standard includes
  89. MNP as an "alternate" method in case a modem is not v.42 compliant ..  in other
  90. words  v.42  modems  can  connect with  MNP  modems  and  achieve  a "reliable"
  91. connection.
  92.  
  93. A commonly asked  question is if  v.32 modems  will work with  v.42 -- and  the
  94. answer is yes and no.   If you asked the question "can I  transmit
  95. an FM RADIO  FREQUENCY and have the  listeners understand" the answer  would be
  96. the same  and for  virtually the  same reasons  (comparing the  v.42 method  of
  97. packetizing data to English and the v.32 method of modulation to FM).
  98.  
  99. The  v.42  and   v.32  standards   are  for  two   completely  different   (but
  100. complimentary) areas of  communication.  In  fact, you'll most likely  discover
  101. that every  v.32 modem  you find  has v.42,  MNP or  some other  kind of  error
  102. correction control built into it.
  103.  
  104. So... a v.32 modem can talk to a v.42 modem -- if the modem on the other end is
  105. a v.32 modem and  if it can understand the v.42 method  of packetizing data (or
  106. the MNP method since MNP is included in the v.42 standard).
  107.  
  108.                   What is the benefits of MNP?
  109.  
  110.  
  111.    MNP (or v.42) provides you with an ERROR CORRECTED session between
  112.    your modem and the modem at the other end of the phone line.
  113.  
  114.    If you have ever logged onto a system and found that you could barely
  115.    read or write messages due to all of the line noise .. then you can
  116.    appreciate the difference between a "clean line" and a "noisy line".
  117.    When both modems have MNP (or v.42) then they are capable of
  118.    filtering out the line noise.  BUT, make no mistake about it - the
  119.    line noise may STILL be there .. it just does not get printed on
  120.    your screen nor the host screen because the modems have filtered it
  121.    out.
  122.  
  123.    This "filtering process" is similar to the error correction protocols
  124.    such as Xmodem or Ymodem.  They send a block of data and a CRC
  125.    together and if the receiving modem finds a different CRC value then
  126.    the two modems resend the data until it is corrected.  So, in the
  127.    same manner that a file transfered with Ymodem is pretty much
  128.    guaranteed to be "correct" after it arrives (even though line noise
  129.    may have caused several re-sends of the data) the same is true of
  130.    data that you see on your screen when using error correcting modems.
  131.  
  132.    The second benefit of MNP (or v.42) is that while it is creating
  133.    data packets for the "error correction protocol" it is able to
  134.    reduce the size of the data by stripping out start and stop bits.
  135.  
  136.    For instance, a normal character takes up 8 bits plus 1 start bit and
  137.    1 stop bit for a total of 10 bits.  On that basis you can figure that
  138.    a 2400 bits per second modem will give you a maximum throughput of
  139.    240 characters per second (because each character is 10 bits long)
  140.  
  141.    The MNP (or v.42) protocol can strip the start and stop bits which
  142.    subtracts 20% of the data and gives you a 20% increase in speed
  143.    (minus a few percentage points for the protocol overhead).
  144.  
  145.    Therefore, without even compressing the data you can expect to see
  146.    as much as 270 characters per second on a 2400 BPS line (versus the
  147.    "norm" of about 235 cps on the same line).
  148.  
  149.    The third benefit of MNP (or v.42) is DATA COMPRESSION.
  150.  
  151.    In the BBS world you are probably aware of files that are ARC'ed or
  152.    ZIP'ed.  The reason for using ARC or ZIP is to decrease the size of
  153.    the file before storing it on disk - and then uncompress the file
  154.    when you want to use it.  This saves disk storage.  When performing
  155.    file transfers it also saves time!
  156.  
  157.    The data compression capabilities of MNP and v.42 are not nearly as
  158.    good as either ARC or ZIP.  But on straight ASCII text they are still
  159.    capable of decreasing the data to about 50% of its size.  Decreasing
  160.    by 50% means that you can DOUBLE the throughput on the line so that a
  161.    2400 bps modem can effectively transmit 480 cps (the speed of a 4800
  162.    bps modem!).
  163.  
  164. Now the drawbacks......
  165.  
  166.    You only get the benefits of MNP (or v.42) if the modem at the OTHER
  167.    END also has MNP (or v.42) built into it.
  168.  
  169.    Data Compression between modems is only effective if the data being
  170.    transferred is NOT ALREADY COMPRESSED.  This means that you can
  171.    expect to see fast transfers on ascii text files - but transferring
  172.    a file that is already compressed (such as an ARC or ZIP file) will
  173.    actually be SLOWER than if the modems did not perform any data
  174.    compression.
  175.  
  176.    Unfortunately, in the BBS world compressed data is more common than
  177.    non-compressed data.  Sure, you'll be able to read messages faster
  178.    (if you can move your eyes that fast!) and you can download bulletins
  179.    and other non-compressed data faster.  But downloads of most files on
  180.    BBS's will actually be slower.
  181.  
  182.    Fortunately, you can usually tell your modem to turn data compression
  183.    off (prior to making the phone call) so as not to slow down your
  184.    file transfers.
  185.                      1 9 2 0 0    B P S    O P E R A T I O N
  186.                      ---------------------------------------
  187.                                  December 27, 1990
  188.  
  189.   We receive a number of comments concerning RBBS-PC operation and the use of
  190.   9600/19200 bps modems.  In order to clarify a few items, the following should
  191.   help in properly configuring your system and in explaining high speed modem
  192.   operation to your callers (and yourself!).
  193.  
  194.   First, some basics.  When a user calls a BBS system, there are generally 3
  195.   links between the two machines which are speed related.  The first is the
  196.   speed or bps rate at which the caller's CPU is connected to their modem, the
  197.   second is the link between the two modems themselves, and the third is the
  198.   link between the host modem and the host CPU.  For simplification, we will
  199.   refer to these three speeds in the remainder of this document as CLink
  200.   (caller CPU to caller modem), MLink (modem to modem), and Hlink (host CPU to
  201.   host modem).  A simple diagram might help here:
  202.  
  203.           --------         --------          -------          -------
  204.           Caller's         Caller's           Host             Host
  205.             CPU             Modem             Modem            CPU
  206.           --------         --------          -------          -------
  207.                            |___  CLink  ___| |___  MLink  ___| |___  HLink  ___|
  208.                 RS-232 Cable     Telephone Line     RS-232 Cable
  209.                  (DTE Link)        (DCE Link)        (DTE Link)
  210.  
  211.   Second, CPS is now used extensively by various communication's programs in
  212.   order that a caller can judge their throughput "performance" during a file
  213.   transfer.  For the benefit of those who do not understand bps rates and CPS,
  214.   here is a very basic outline.  Generally, a byte of data (one character) is
  215.   sent as a start bit, followed by the actual character, followed by a stop
  216.   bit.  When running at 7,E,1, the highest character which can be sent is a
  217.   chr$(127).  However, that means you can not send any "binary" files which
  218.   usually contain many characters from chr$(128) to chr$(255).  However, when
  219.   using 8,N,1 settings, any of these "high order" characters can be transmitted
  220.   - which not only allows for the transmission of binary files, but also allows
  221.   for the use of "graphics" display files which are comprised of many of these
  222.   high order characters.  Now, if we add the start bit, plus the 8 bit
  223.   character length, plus the stop bit, we end up with 10 bits needed to send
  224.   one character (or a single byte of data) to the other machine.  At 1200 bps,
  225.   (1200 bits per second), if we divide the bps rate by 10 (the number of bits
  226.   per byte), we end up with a maximum throughput rate of 120 characters per
  227.   second (or 120 bytes per second if you will).  Similarly, at 2400 bps, the
  228.   theoretical maximum rate would be 240 characters per second.  That is why
  229.   when doing an ASCII file transfer, CPS rates equal to bps rate/10 can be
  230.   achieved.  However, when doing protocol transfers, the time delay
  231.   blocks, as well as block "error checking" bytes which are added to chunks of
  232.   data, end up cutting down the actual throughput rate of the given file so
  233.   that something in the order of 85% effective rate is achieved.  So, how do
  234.   some of the new modems do BETTER than the bps rate/10?  Simply, they
  235.   "compress" the data to be sent using compression algorithms similar to those
  236.   used when ARC'ing a file - so that they can send more bytes of the file at
  237.   one time.  Of course, the modem on the opposite end must be able to "un-
  238.   compress" the data - or the whole thing falls apart!  Also, since the modems
  239.   themselves are handling all error checking, there is no need for the software
  240.   to control the sending of blocks and "waits" for an good acknowledgement.
  241.   All it (the software) needs to do is send the file out to the other end -
  242.   monitoring RTS/CTS flow control in the process.  What all this ends up doing
  243.   is allowing some of the new high speed modems to produce CPS throughput rates
  244.   of 1100 to 1600 CPS or higher under ideal conditions - including "clean"
  245.   lines, maximum "horsepower" CPU's and hard disks, etc.
  246.  
  247.   Third, we need to mention a little bit about flow control.  Generally
  248.   speaking, there are two types of flow control - XON/XOFF and CTS/RTS
  249.   checking.  XON/XOFF is the "standard" flow control which has been used for
  250.   years in async communications.  It is done by having one CPU send the other
  251.   CPU's software a signal to start or stop transmitting data.  This works great
  252.   at baud rates up to about 4800 baud, as long as there is a "buffer" of
  253.   adequate size on both machines, and the two softwares "look for"
  254.   fairly frequently during ALL of their processes.  If they do not check for
  255.   the appropriate signal often enough, and their communication's buffer is not
  256.   large enough, one machine can keep sending data to the other - even though
  257.   the other is not ready to receive it - causing a loss of data.  Most programs
  258.   on the market today monitor XON/XOFF checking very well, and have no problems
  259.   with flow control at the lower speeds.  However, when operating at rates of
  260.   9600 bps and above, data can be sent back and forth so quickly, a quicker and
  261.   more reliable method of controlling the flow of data must be implemented.
  262.   Here we use RTS/CTS (Ready to Send/Clear to Send) flow control.  What happens
  263.   is that in effect, hardware bits are toggled to immediately trigger the
  264.   necessary start/stop sequences to prevent data over-runs.  Although the two
  265.   software programs must continually monitor the CTS/RTS bits, it can usually
  266.   be done much more quickly and effectively than having to check for the
  267.   XON/XOFF software signals.
  268.  
  269.   Now, we know there are three links between the two machines, and that there
  270.   must be good flow control in order to prevent data loss.  What some don't
  271.   realize is that EACH link can run under it's own flow control!  In other
  272.   words, the CLink must have proper flow control, the MLink as well, and of
  273.   course the HLink too.  If you consider that the caller may only be using
  274.   XON/XOFF flow control for the CLink portion, while the host CPU is trying to
  275.   only use RTS/CTS flow control for the HLink, and the two modems are using
  276.   neither, you can imagine the problems that may develop in trying
  277.   data from being lost or corrupted!
  278.  
  279.   So, how do we as sysops figure out how to set up our "host" modems and
  280.   HLinks, plus, how do we educate our caller's to properly set up their
  281.   hardware and software links?  Unfortunately, with the large variations in
  282.   current 9600 baud modem technology and configuration settings - that can be
  283.   VERY difficult.  But, let's take it a step at time in general terms.  First,
  284.   let's tackle the host side.
  285.  
  286.   When hooking up a 9600 bps modem on your host CPU, you need to determine your
  287.   HLink speed of operation and type of flow control.  If you are running on a
  288.   "slow" machine, or under some sort of multi-tasking software where the
  289.   hardware may not be able to keep up with full 19200 bps flow, you will have
  290.   to limit yourself to a maximum rate of 9600 bps or lower in order to insure
  291.   reliable operations.  However, if your hardware can support a full 19200 bps
  292.   HLink, then you need to change some of your modem settings vs the sysop who
  293.   will be using 9600 bps as their HLink speed.  Why?  Because of the way
  294.   RBBS-PC operates.  If the opening speed of the modem is 9600 bps or lower,
  295.   RBBS-PC has been written to allow the HLink to AutoBaud to match the speed of
  296.   the MLink.  However, if the opening speed is 19200, RBBS-PC assumes that the
  297.   sysop wants to "lock-in" the maximum throughput rate, and does NOT AutoBaud
  298.   the HLink to try and match the MLink (with the exception of the Hayes 9600 V-
  299.   Series modem.  See note at end of document)!  So, how do we make adjustments
  300.   in the modem settings?  First, a word about AutoBauding and what happens.
  301.  
  302.   AutoBauding is simply a term to describe the ability of the host software to
  303.   change the speed of the HLink to match that of the MLink.  Here's how it
  304.   works.  A caller sits down to their machine.  They decide to call XYZ board
  305.   across town.  They are using an ACME 1200 bps modem.  XYZ BBS across town is
  306.   using a GENERIC 2400 bps external modem - which the sysop has set up with an
  307.   initial port opening speed of 2400 bps.  XYZ sysop brings his/her board up
  308.   on-line.  RBBS-PC opens the com port at 2400 bps (the async card is now set
  309.   to operate at 2400 bps).  Likewise, the modem at XYZ board also responds at
  310.   2400 to the initial commands and is ready to answer the phone.  The caller
  311.   dials XYZ board, and the board gets a ring detect.  At that time, RBBS-PC
  312.   sends the modem an "ATA" command to answer the phone.  This is done of course
  313.   at 2400 bps.  The modem goes into auto-answer mode and starts it's initial
  314.   handshaking with the caller's modem.  First, it tries to establish a good
  315.   connection at 2400 bps.  Since it fails, it drops down to 1200 bps and tries
  316.   again.  Success!  The modem-to-modem link (MLink) is now at 1200 bps.  The
  317.   modem now sends a "CONNECT xxxx" message to the host CPU via the HLink at
  318.   2400 bps.  The host software looks over the response and is told that the
  319.   connection was made at 1200 bps and not 2400 bps.  Since the connect message
  320.   is the LAST command the modem will send to the host via the HLink at 2400
  321.   bps, the host CPU must automatically drop down to 1200 bps, or all future
  322.   data transfers on the HLink will be garbage.  So, the host software
  323.   in this case), immediately adjusts the async card's bps rate divisor
  324.   "latches" on the fly - so that the HLink is now at the same speed as the
  325.   MLink - which is of course also the same speed as the CLink.  Now that all
  326.   the links are "talking" at the same speed, data starts to flow normally
  327.   between the two machines.  One exception here.  RBBS-PC of course expects the
  328.   caller to be at 8,N,1 modem settings.  If the call is not at the proper
  329.   settings, it recognizes the fact and sends the caller the message indicating
  330.   they should switch to 8,N,1 before trying their call again.  Now, all of this
  331.   works fine if the host modem is able to quickly change speeds to match the
  332.   caller, and it properly returns the correct "CONNECT xxxx" message to
  333.   RBBS-PC.  The older 300/1200/2400 bps modems usually have no problems with
  334.   this.  However, enter the world of 9600 bps modems - where there is yet no
  335.   "standard" among the various manufacturers on how the MLink should be
  336.   established!  Plus, based on the firmware in the modem itself, some may have
  337.   a great deal of trouble in dropping down from the higher speeds to the lower
  338.   speeds in an attempt to establish a good carrier (MLink) with the caller.
  339.   And, since the sysop has the option of either allowing the HLink to stay at a
  340.   fixed rate or to AutoBaud to match the MLink, things start to get a little
  341.   messy.
  342.  
  343.   So, what does the sysop do to properly configure their system if they want to
  344.   run one of the new 9600 bps modems?  First, they must of course decide upon
  345.   the brand of modem they will use.  Since each of the 9600 bps modems use a
  346.   different technique for handling full duplex operations (i.e. the ability of
  347.   the caller to see on their screen the character they typed in a reasonable
  348.   amount of time), the sysop must be careful to purchase a modem which will
  349.   meet their needs in "interactive throughput".  Since some 9600 bps modems are
  350.   not actually operating in a full async mode (i.e. they are simulating what
  351.   normally happens at bps rates of 2400 and below in the modem's ability to
  352.   send and receive data at the same time), there can be long delays between
  353.   when the caller presses a key on their keyboard and when they see the
  354.   character on their screen.  This is very annoying and also usually means file
  355.   transfer throughput rates may be affected in a similar manner.  Second, they
  356.   must consider how well the modem will work in day-to-day operations in
  357.   handling the ability to establish a good carrier with the caller - regardless
  358.   of the speed of the HLink and the quality of the line.  Third, the sysop
  359.   should consider how easy it will be to configure the modem to operate
  360.   reliably.  If it requires the sysop to have a PhD in figuring out the modem
  361.   manual and the all the various combinations of settings, you may want to
  362.   check out a different brand of modem!
  363.  
  364.   So, a modem is finally selected and is ready to be installed.  Now, we get
  365.   back to the question of what speed are we going to set up the HLink at -
  366.   since IT determines how the host modem should be configured!  If it is
  367.   decided that the HLink is going to be 19200 bps (the host hardware can safely
  368.   handle full 19200 bps operations), the sysop needs to set up the Comm port so
  369.   that the HLink ALWAYS stays at 19200 - since that is what RBBS-PC is going to
  370.   do!  If 9600 bps is the highest speed which will specified, then the modem
  371.   MUST be configured to allow for AutoBauding to occur (See Hayes 9600 V-Series
  372.   modem note at end of document).  In either case however, the sysop MUST
  373.   enable RTS/CTS flow control!!
  374.  
  375.   At this point, the sysop should check their manual for the appropriate modem
  376.   setting to accomplish the above.  Note that the manual will probably indicate
  377.   not only a "send" flow control parameter, but a "receive" one as well.  In
  378.   that case, all should be set to allow for CTS/RTS flow control!  CAUTION:  IF
  379.   YOU ARE GOING TO BE RUNNING AT EITHER 9600 OR 19200 Bps, AND YOU DISABLE
  380.   RTS/CTS FLOW CONTROL WHEN CONFIGURING THE HOST MODEM, NEITHER IMODEM OR
  381.   YMODEM-G PROTOCOL TRANSFERS WILL WORK RELIABLY - SINCE DATA OVER-RUNS ARE
  382.   SURE TO OCCUR!!!
  383.  
  384.   Also, some modems which use MNP error checking, allow the modem to either
  385.   "look for" another MNP modem, or to ignore the fact that there may be another
  386.   MNP modem calling in.  Since the time to "look for" another MNP modem can
  387.   take up to 6 seconds, the sysop should be aware that their caller's may get a
  388.   delay between the time the phone answers the caller and when the "Connection
  389.   Established" message is sent.  Likewise, if the caller has "look for another
  390.   MNP modem" enabled on their end, while the host modem DOES NOT, the host may
  391.   send the "Connection Established" message to the caller - but since the
  392.   caller's modem is still trying to look for another MNP modem, the initial
  393.   data will be lost to the caller and will NOT appear on their screen.  This
  394.   becomes very confusing for not only the caller, but the sysop as well in
  395.   trying to figure out why some callers are loosing the initial logon message,
  396.   while others receive it fine.  Unfortunately, the only answer to all of this
  397.   is education on the part of the callers as well as the sysops.  They both
  398.   need to have an understanding of high speed communications and the various
  399.   modem's characteristics if they want to enter the high speed arena.  It is no
  400.   longer simply a matter of plugging in a modem, setting a few switches, giving
  401.   the modem a few simple commands, followed by totally reliable unattended
  402.   operation.
  403.  
  404.   If all/any of the above makes sense, the next question usually asked by the
  405.   sysop is "Gee, where do I find out about all this stuff and still - no one
  406.   has told me how to set up my modem!"  Unfortunately, there are very few
  407.   single sources of information on how all of the various brands of new 9600
  408.   bps modems operate - including the various commands needed to properly
  409.   configure them for both the caller as well as the sysop.  For example, the US
  410.   Robotics Courier HST modem, when operating at 9600 bps, uses a USR
  411.   proprietary means of communication.  However, at 1200/2400 bps, it can be
  412.   configured to "talk" to other MNP based modems!  So, the sysop must be able
  413.   to relate 1200/2400 bps MNP settings to other MNP modems, while considering
  414.   USR settings for 9600 bps and above.
  415.  
  416.   What all this boils down to is that RBBS-PC SysOps are frequently asked if we
  417.   can provide the necessary settings for the various 9600 bps and other modems
  418.   which will allow all of this to work properly.  At present, the answer
  419.   unfortunately is no.  We have neither the time or resources to become
  420.   thoroughly knowledgeable on all of the various brands of 9.6 modems in order
  421.   that they can be properly configured under the following settings:
  422.  
  423.      1. Callers who want their CLink to be at a fixed rate
  424.      2. Callers who want their CLink to auto-bps
  425.      3. Sysops who want their HLink to be at a fixed rate
  426.      4. Sysops who want their HLink to auto-bps
  427.  
  428.   As can be seen, multiplying the above by the number of 9600 bps modems on the
  429.   market, and then compounding this effort with the fact that there are
  430.   currently a lot of ROM changes (hence modem setting changes) going on in the
  431.   industry - it is virtually impossible for any one source to remain current on
  432.   everything associated with 19200 bps.  Therefore, possibly the best source of
  433.   information, and obviously most current, should be the modem manufacturer
  434.   themselves.  Hopefully, they will be fairly familiar with the software that
  435.   is being used at both ends of the connection to provide sufficient
  436.   information on the proper modem settings to use under those conditions.
  437.   However, we do use a default modem setup program, that we use to configure
  438.   modems tested on this system for operation.  We have found that when using
  439.   the settings in the RBBS-PC program, we are able to successfully operate
  440.   the Hayes 2400, Hayes 9600 V-Series, US Robotics Courier HST, Microcom
  441.   AX9624C and Prometheus ProModem modems with the 17.3 version software, with
  442.   some minor updates from modem manufactures and (Alot of old fashioned
  443.   guesswork!)
  444.  
  445.   Here are a few other bits and pieces of information concerning 9600/19200 bps
  446.   operation that are frequently discussed:
  447.  
  448.   Question:    "Why is it that on the local (host) screen, it appears that the
  449.                caller is using XON/XOFF flow control when operating the host at
  450.                19,200 bps?"
  451.     Answer:    What is usually happening here is that the host modem may have
  452.                an internal buffer to store up to 8K of data it receives from
  453.                the host CPU via the HLink.  It then funnels the data out to the
  454.                caller at the MLink speed.  So, what the sysop usually sees on
  455.                the host side is a little blip of data going to the modem as
  456.                almost an entire screen of data is sent to the host modem and
  457.                buffered there.  Then, the host modem dribbles out the data to
  458.                the caller at the MLink speed.  No lights are usually present on
  459.                the host modem to indicate that the data is actually being sent
  460.                to the caller - since the TD or SD (transmit data or send data)
  461.                light ONLY flashes when the host CPU sends data to the host
  462.                modem via the HLink - NOT when the host modem is sending to
  463.                the caller's modem via the MLink.  What this ends up looking
  464.                like is 3/4 of a screen display appearing almost instantaneously
  465.                on the host, followed by a delay, followed by another quick
  466.                screen display, followed by a delay.  This is normal, and you
  467.                have to remember that the caller is simply seeing what they
  468.                always do at the speed at which they are connected - rather than
  469.                at 19200 bps.  The pauses are caused by having properly defined
  470.                your CTS/RTS flow control parms - since when the host modem's
  471.                buffer is full, it signals (by toggling the RTS/CTS signals),
  472.                the fact that the host CPU should delay sending it (the host
  473.                modem), and more data until it has had a chance to empty out
  474.                it's internal buffer to the caller.
  475.  
  476.   Question:    "My callers are complaining that since installing a 9600 bps
  477.                modem and running it at 19200 on the HLink, they are no longer
  478.                able to (Ctrl-K) abort a "non-stop" listing, or are unable to
  479.                interrupt a long message display.  What's wrong with my settings
  480.                or the software?"
  481.     Answer:    Nothing is wrong with either of them!  Your callers are simply
  482.                trying to perform functions against the internal buffer of the
  483.                host modem - over which you and/or the software may have no
  484.                control.  When operating the host at 19200 as indicated above, a
  485.                whole screen of data can be sent to the modem in a
  486.                second.  There it will be buffered until it is sent to the
  487.                caller at the speed at which they can accept it.  So, for
  488.                example a complete message can be sent to the host modem - after
  489.                which the host pauses awaiting the caller's response to a "More"
  490.                prompt.  In the meantime, the caller is just barely starting to
  491.                have the message displayed on their local screen.  They decide
  492.                they want to (Ctrl-K) abort it.  So, they press (Ctrl-K).  Since
  493.                the host has already sent all the data is going to, and the host
  494.                modem will not recognize the (Ctrl-K) as a signal to flush out
  495.                what is in it's buffer, the caller continues to receive the data
  496.                from the host modem until it's buffer is empty.  The slower the
  497.                MLink speed, the worse this situation will be.  If your caller's
  498.                software supports the sending of a BREAK signal to your modem,
  499.                and your modem supports the "dumping of it's buffer upon receipt
  500.                of a BREAK signal, this delay can be defeated.
  501.  
  502.   Question:    "If this is the case above, why not let me define the host
  503.                modem's buffer size?"
  504.     Answer:    That is between you and the modem manufacturer and the various
  505.                settings they allow.  However, decreasing the internal buffer
  506.                size of the host modem may degrade the modem's ability to
  507.                operate up to it's advertised speed.
  508.  
  509.   Question:    "On my system, the best download CPS rate that any of my callers
  510.                get when using my new GENERIC 9600 bps modem is 700 cps.  But,
  511.                on my friends system down the street, I see his caller's getting
  512.                over 1000 cps all the time!  What am I doing wrong?"
  513.     Answer:    Possibly nothing!  Some of the things that can cut cps figure
  514.                down VERY quickly are: 1)CPU speed, 2)multitasking the host CPU,
  515.                3)speed of the host hard disk, 4)line quality, 5)modem settings,
  516.                etc.  Any of the above can make subtle differences in your
  517.                caller's CPS throughput.  Remember, at 9600 bps, an increase of
  518.                1 second in the time it takes to send a given piece of
  519.                information can have dramatic effects on throughput rates -
  520.                since ideally 1 second will cause a "loss in effectiveness" of
  521.                approximately 1000 bytes!
  522.  
  523.   Question:    "Should I buy a 9600 bps modem, and which one should I buy?"
  524.     Answer:    Sorry, but that question can only be answered by you after
  525.                determining your needs, the needs of your callers, and what you
  526.                feel you can afford.  Remember, at present there are very few if
  527.                any "standards" among the 9600 bps modem manufacturers - which
  528.                normally means only "like manufactured" modems can talk to each
  529.                other at 9600 bps.  So, if you decide to buy one, only callers
  530.                who have the same brand of modem will be able to take advantage
  531.                of your "new technology".  Second, your users will have a
  532.                tendency to look to you for leadership in what modem they should
  533.                buy so that they can talk to your system at the higher rates of
  534.                speed.  If you recommend they go out and by an ACME 9600 bps
  535.                modem for $1,000, and 3 months from now the GENERIC 9600 modem
  536.                at $595 becomes the defacto "standard" which everyone else is
  537.                buying and running, your caller's will be understandably a
  538.                little upset with you for influencing their buying decision in
  539.                the wrong direction.  You are assuming a lot of responsibility
  540.                as a BBS SysOp when you bring a system up on-line.  Callers
  541.                will expect that you are a leader in the area because of your
  542.                choice of software.  Be prepared to live up to their
  543.                expectations.
  544.  
  545.   Question:    "Why is there a delay between what the caller types at their
  546.                keyboard and what they see on their screen?"
  547.     Answer:    At 2400 bps and below, the modem(s) can send and receive data at
  548.                the same time.  Therefore, the "turnaround" time, (the time it
  549.                takes the caller to send the keystroke to the host, and for the
  550.                host to send it back to the caller for display on their screen)
  551.                is very short - measured in fractions of a second.  However, at
  552.                9600 bps, most modems are not operating in "true" async mode
  553.                with instantaneous turnaround.  Instead, they are "simulating"
  554.                async operations - since they are also providing full error
  555.                checking of the data that is being sent and received.  In order
  556.                to do this, several schemes can be used.  However, the end
  557.                result is that at 9600 bps and above (under current technology),
  558.                turnaround time may be higher at 9600 bps than it would be if
  559.                the caller were at 2400 bps.  Some modems are better than
  560.                others.  Some are very bad.  You should check around to find one
  561.                that will meet your expectations.  A $400 9600 bps modem which
  562.                is prone to errors and has terrible turnaround time is not a
  563.                "bargain".  Make sure you are getting what you paid for.
  564.                Remember also, that just because you can buy a certain brand of
  565.                modem cheaply does not mean your callers can automatically do
  566.                the same.  If your callers can't afford a modem which will talk
  567.                to yours, your money has also been wasted.
  568.  
  569.   Question:    "I am running under a network environment.  What should I set my
  570.                upload buffer size to be inside RBBS-PC to insure maximum
  571.                throughput during uploads to my system?"
  572.     Answer:    That depends on the speed of your network, the speed of your
  573.                hard disk, the type CPU's and UARTs you are using, and your
  574.                over-all network activity.  For most networks, although it may
  575.                sound strange, you may get BETTER throughput during uploads if
  576.                you set your buffer size to 4 or 8 blocks!  Only if you are
  577.                running in a true "standalone" environment with a fast
  578.                and/or a very fast network (10 meg throughput) will a large
  579.                buffer size usually benefit you or your callers.  The reason
  580.                being is that most networks will more efficiently handle a small
  581.                packet transfer request on a more frequent basis than they will
  582.                a large one - based on other network activity.  The ability to
  583.                define an "Upload Buffer" size in the RBBS-PC program can
  584.                provide increased throughput to some systems - especially those
  585.                running high speed modems.  However, by defining a good size
  586.                buffer, you are going to be allocating additional low memory for
  587.                the buffer.  This usually has minimal effect on a system running
  588.                in standalone mode, or in a true network environment.  However,
  589.                if you are running under multitasking software, you may have
  590.                problems if you try and define your upload buffer too large.
  591.                You will run out of memory and get all sorts of strange error
  592.                messages.  The best recommendation we can provide is to start
  593.                with a buffer size of 4 blocks and work up from there.  If no
  594.                strange errors occur, increase the number in 4 block increments.
  595.                We suggest NOT exceeding 32 buffers max for a multitasking
  596.                environment.
  597.  
  598.   Question:    "My PC Pursuit callers are really griping about the new code and
  599.                my new 9600 bps modem!  Seems none of them can download anymore!
  600.                What did you mess up in the new code?"
  601.     Answer:    Nothing!  The routines used in 17.3 are the same as those used
  602.                in previous versions.  The problem centers around PC Pursuit and
  603.                the communication's program they are using.  What happens is if
  604.                you are operating your HLink at 19200 and PC Pursuit is a little
  605.                busy, the caller's communication's program may abort - since PC
  606.                Pursuit is not geared up to handle the high rate flow of data
  607.                being given it.  To correct for the condition, have your
  608.                caller's select "relaxed" protocol transfer type in their
  609.                communication's program, install a Zmodem DOOR application, or
  610.                drop your HLink down to 9600 bps.  Additionally, some of the
  611.                communications program they (your callers) are using are very
  612.                sensitive to timing problems on their end.  You can also suggest
  613.                that they try a different communications program.
  614.  
  615.   In summary, folks purchasing one of the new 9600 bps error correcting modems
  616.   hope the new modem will really make their system file transfers fly.
  617.   Unfortunately, some will find that 19200 will not work on their system.  The
  618.   reasons are many, but basically boil down to what type UART(s) and CPU the
  619.   system is using, what brand modem(s) the board is running, whether the sysop
  620.   is running any software which must control the COM port buffer interrupts
  621.   (this includes all multitasking software, etc.), and how the system intends
  622.   on supporting PC Pursuit callers.  Unfortunately, some multitasking software
  623.   is unable to efficiently time slice concurrent 19200 bps operations on one
  624.   or more partitions, causing device timeouts when the opposite partition
  625.   attempts to output anything to it's respective COM port.  RBBS-PC attempts to
  626.   trap for as many of these timeout conditions as possible.  However, in some
  627.   cases, the multitasking software may NEVER "release" the opposite COM port,
  628.   causing that node to effectively loose it's COM port.  This has the effect of
  629.   shutting down that node.  Additionally, even if 19200 does work under your
  630.   multitasker, you may find that file transfers are SLOWER than at a straight
  631.   9600 bps setting.  The reason again is the way the interrupts are handled and
  632.   the amount of timeout errors which are necessarily being trapped by the code.
  633.   Basically, if you experience a large number of errors while trying to run one
  634.   or more nodes at 19200 bps, you will have to set your modem open speed to a
  635.   max of 9600 bps.  Additionally, if the CPS throughput is less at 19200 that
  636.   it was at 9600, you will likewise be best to set back your modem speed to
  637.   9600 max.  Please note that the additional throughput gained by running the
  638.   host modem in a locked 19200 bps setting is minimal compared to straight 9600
  639.   bps.  Plus, the chances of getting a device timeout on another node is much
  640.   less when running at 9600 rather than 19200.  19200 will work best for those
  641.   folks running either true networking systems who have "tuned" their network
  642.   for maximum throughput, or for those running 19200 in a single node
  643.   standalone mode.  We estimate 95% of all multitasker sysops will find that
  644.   9600 bps is the maximum speed they will be able to operate their nodes
  645.   reliably.
  646.  
  647.  
  648.  
  649.  
  650.   RBBS-PC DOOR operations at 19200 now also present a unique problem.  After
  651.   reading the above, it is easy to see why some DOOR application programs may
  652.   have difficulty running under a 19200 bps configuration.  If the DOOR program
  653.   does not take into consideration the fact that at a modem opening speed of
  654.   19200 the HLink is to always remain at 19200, it can attempt to AutoBaud the
  655.   HLink - totally messing up the pre-established links.  The value in the
  656.   DORINFO(X) file may indicate 2400 bps, which would be the speed at which the
  657.   MLink was established.  However, if the sysop has opened their host computer
  658.   at 19200, that 2400 value should then be used for informational purposes
  659.   only!  The DOOR application should therefore check BOTH the CALLERS file
  660.   as well as the DORINFO(X) file in order to gain ALL the information needed
  661.   to properly handle their application.
  662.  
  663.  
  664.   Hayes 9600 V-Series Notes
  665.   -------------------------
  666.   RBBS-PC 17.3 fully supports the new Hayes 9600 V-Series modem at all speeds -
  667.   including 19200, 9600 and lower bps rates.  However, since the Hayes 9600 V-
  668.   Series operates entirely different than the other current 9.6 modems on the
  669.   market, it is essential you understand the difference if you intend on using
  670.   a Hayes in your operation.  Most of the new 9.6 modems allow setting the
  671.   HLink to a fixed speed of operation - regardless of the speed of the caller.
  672.   However, the Hayes V-Series does NOT allow holding the HLink at a fixed rate
  673.   UNLESS it detects an "error-correction" connection!  Which means that IF AND
  674.   ONLY IF the caller is using another error correcting V-Series modem and they
  675.   establish an error-correction link, will the Hayes on the host stay at the
  676.   fixed DTE or HLink speed.  Under ALL other conditions, the Hayes 9600 V-
  677.   Series will autobaud down to match the speed of the caller - even though the
  678.   port was opened at 19200 on the host.  DOOR authors must consider this when
  679.   writing their applications for sysops with a Hayes 9600 V-Series on-line.  In
  680.   order to detect this, a DOOR author should interrogate the RBBS environment
  681.   for the "/DTE" parm and adjust accordingly - based on the "Error Correcting
  682.   Modem" flag in the DORINFO(X) file as well.
  683.  
  684.  
  685.   Sidenote
  686.   --------
  687.   A sidenote when configuring your high speed modem to operate at a maximum
  688.   speed of 9600 bps.  When you configure your modem's opening speed to be 9600
  689.   instead of 19200, some of the problems indicated above (such as failure to
  690.   quickly detect a (Ctrl-K), etc.) are no longer a problem - since the code
  691.   will automatically AutoBaud the modem to match the caller's connect speed.
  692.   Since under that condition, output from the code is much more closely aligned
  693.   to the speed at which the caller is able to receive the data, normal (Ctrl-K)
  694.   operations are restored.  Additionally, the Hayes 9600 V-Series modem
  695.   automatically AutoBauds down unless an error-corrected connection is
  696.   established - which means it as well will properly handle a caller's (Ctrl-
  697.   K) requests.  So, the bottom line is, do you want to provide better support
  698.   for your low speed callers, or do you want to insure the maximum throughput
  699.   for your high speed ones?  The question of how you want to support the
  700.   majority of your callers rests entirely with you.  You need to decide what
  701.   course of action you wish to take when configuring a 9600 bps high-speed
  702.   modem.
  703.  
  704.  
  705.                           End of RBBS19200 Documentation
  706.  
  707.  
  708. RBBS-PC Operation with the Microcom AX2400c MNP-5 Modem
  709. --------------------------------------------------------
  710. The following is a listing of Modem settings and configuration
  711. information for the use of a Microcom AX2400c with RBBS-PC operation,
  712. this setup allows callers at all baud rates to connect and perform
  713. normal operations.
  714.  
  715.  
  716.  
  717. ->  Modem Firmware Version (AT%V)
  718. ---------------------------------
  719.  
  720. MNP Class 5 2400 Modem Rev 4.3
  721.  
  722. -> Switch Settings (Front AT%S0 - Rear AT%S1)
  723. ---------------------------------------------
  724.  
  725. FRONT 1 2 3 4 5 6 7 8 9 10
  726.       U D D D D U U D U U
  727.  
  728. REAR  1 2 3 4 5 6 7 8
  729.       D D D U D U D U
  730.  
  731. -> Command Settings (AT\S)
  732. --------------------------
  733.  
  734. IDLE           000:00:00
  735. LAST DIAL
  736. ID:
  737. MODEM BPS      2400   AT
  738. MODEM FLOW     OFF    AT\G0
  739. MODEM MODE     AUT    AT\N3
  740. AUTO ANS.      OFF    ATS0=0
  741. SERIAL BPS     2400   AT
  742. BPS ADJUST     OFF    AT\J0
  743. SERIAL FLOW    BHW    AT\Q3
  744. PASS XON/XOFF  OFF    AT\X0
  745. PARITY         8N     AT
  746. BREAK          5      AT\K5
  747. EXIT CHAR      043    ATS2=43
  748. CMD ECHO       OFF    ATE0
  749. RESULTS        ON     ATQ0
  750. RESULT TYPE    MNPL   ATV1\V1
  751. DATA ECHO      OFF    AT\E0
  752. INACT TIMER    00     AT\T0
  753. AUTO RETRAIN   ON     AT%E1
  754. COMPRESSION    OFF    AT%C0
  755. MAX BLK SIZE   256    AT\A3
  756. AUTO BUFF      2      AT\C2
  757. AUTO CHAR      013    AT%A13
  758. MNP BLOCK      OFF    AT\L0
  759. IP PROTO       OFF    AT\I0
  760. EMULATING HP   OFF    AT\H0
  761. PAUSE TIME     002    ATS8=2
  762. DTR            2      AT&D2
  763. CARR DET       1      AT&C1
  764. DSR            0      AT\D0
  765. RING IND       1      AT\R1
  766. SPEAKER CTRL   1      ATM1
  767. LEASE LINE     OFF    AT&L0
  768. ASYNC/SYNC     0      AT&M0
  769. CTS/RTS        ON     AT&R0
  770. RDLB ENABLE    OFF    AT&T5
  771. DIAL MODE      4      ATX4
  772. PULSE DIAL     US     AT&P0
  773. GUARD TONE     0      AT&G0
  774. BELL           ON     ATB1
  775. DISC DELAY     000    AT%D0
  776. REM CHAR       000    AT*S0
  777. REM ENABLE     OFF    AT*E0
  778. REM SEC        OFF    AT*R0
  779.  
  780. -> S Register Default Settings (AT%R)
  781. -------------------------------------
  782.  
  783. REG  DEC  HEX    REG  DEC  HEX
  784. S00  000  00H    S14  008  08H
  785. S01  000  00H    S15  000  00H
  786. S02  043  2BH    S16  000  00H
  787. S03  013  0DH    S17  000  00H
  788. S04  010  0AH    S18  000  00H
  789. S05  008  08H    S19  000  00H
  790. S06  002  02H    S20  000  00H
  791. S07  030  1EH    S21  048  30H
  792. S08  002  02H    S22  118  76H
  793. S09  006  06H    S23  022  16H
  794. S10  030  1EH    S24  000  00H
  795. S11  000  00H    S25  005  05H
  796. S12  050  32H    S26  000  00H
  797. S13  000  00H    S27  064  40H
  798.  
  799.  
  800.  
  801.  
  802. -> RBBS-PC Settings
  803. --------------------
  804. Seconds to Wait for Carrier      :  22
  805. Opening Baud Rate (300-38400)    :  9600
  806. Modem Init. String               :  ATS2=255V1X4M0H0
  807. Modem Off-Hook String            :  ATM0H1
  808. Disable CTR/RTS Checking         :  N
  809. Keep Modem at Opening Speed      :  N
  810. Reset Modem During Recycle       :  Y
  811. Modem Off-Hook Durine Recycle    :  Y
  812. Answer on True Ring Detect       :  N
  813. Allow Callers at 7,E,1           :  N
  814. Allow 300 Baud Callers           :  N (This is just a personal preference and
  815.                                        does not affect operations either way)
  816.  
  817.  
  818.  
  819. Notes:
  820. ------
  821.  
  822. These Settings and Initilization Strings have worked just fine for me
  823. with callers from 300 to 2400 baud.  A 16550 UART was used in the 8mhz
  824. IBM AT's serial port as we are running a Lantastic Network and were
  825. experencing occasional Serial Input errors during Zmodem Uploads.  An
  826. Alternative was to use the command "Handshake Slow" for DSZ, but it does
  827. slow transfers down a bit.
  828. I never experienced any problems with 300 baud callers, despite the note
  829. in the modems manual that says 300 baud is not supported with the AX2400C
  830.  
  831. Greg Pal
  832. SysOp, NoPlace BBS
  833. 12/24/96/19.2b v.32 MNP
  834. (317)345-2375
  835.